I can't reproduce the failing test by running the docker image locally so I added some minor code for outputting the errors.

By the way, what do you think about throwing in a docker-compose.yml file into the repo for easier self-hosting of the API?

Hmm - this time 6.5 and latest passed. Any clue why?

CodSpeed Performance Report

Merging #126 will not alter performance

_{Comparing Rolv-Apneseth:test-later-languagetool-versions (4838e40) with v3 (a90bd15)}

Summary

✅ 6 untouched benchmarks

Looks good! Failing checks are not relevant for this PR :-)

Hmm - this time 6.5 and latest passed. Any clue why?

No clue, but there is no reason why it should fail (the exception is that LT could change detect new errors that were not covered before, which could break our tests, but not the API itself). LT hasn't changed its API in almost two years, I think.

I can't reproduce the failing test by running the docker image locally so I added some minor code for outputting the errors.

By the way, what do you think about throwing in a docker-compose.yml file into the repo for easier self-hosting of the API?

I rarely use Docker, but I am open to better / more reproducible ways to self-host a server. The current ltrs docker commands are quite simple, and probably not bulletproof.

I rarely use Docker, but I am open to better / more reproducible ways to self-host a server. The current ltrs docker commands are quite simple, and probably not bulletproof.

Probably not be necessary, I'm just a big fan of docker compose due to the declarative style. I can just define everything that's needed from a single yaml. I'll just leave the content here for future reference in case (I'll probably come back to find this):

version: "3"

services:
  languagetool:
      image: erikvl87/languagetool:latest
      ports:
      - 8010:8010
      environment:
      - langtool_languageModel=/ngrams
      - Java_Xms=512m
      - Java_Xmx=1g
      volumes:
      - ./data:/ngrams

I rarely use Docker, but I am open to better / more reproducible ways to self-host a server. The current ltrs docker commands are quite simple, and probably not bulletproof.

Probably not be necessary, I'm just a big fan of docker compose due to the declarative style. I can just define everything that's needed from a single yaml. I'll just leave the content here for future reference in case (I'll probably come back to find this):

version: "3"

services:
  languagetool:
      image: erikvl87/languagetool:latest
      ports:
      - 8010:8010
      environment:
      - langtool_languageModel=/ngrams
      - Java_Xms=512m
      - Java_Xmx=1g
      volumes:
      - ./data:/ngrams

Nice! Is it possible to opt out of the ngrams? It is a good default, but also takes more memory I guess.

Nice! Is it possible to opt out of the ngrams? It is a good default, but also takes more memory I guess.

I won't lie I don't know what that is as I'm not too familiar with languagetool itself, I just grabbed the default docker compose that was given for some languagetool docker image. However, reducing it to this still seems to work and allows all the tests to pass:

version: "3"

services:
  languagetool:
      image: erikvl87/languagetool:latest
      ports:
      - 8010:8010
      environment:
      - Java_Xms=512m
      - Java_Xmx=1g

docker compose up -d
LANGUAGETOOL_HOSTNAME=http://localhost LANGUAGETOOL_PORT=8010 cargo nextest run --all-features

N grams are sequences of n grammar tokens (not sure about the work) that you find in a given language and the probability to find it. The ngram dataset contains many such examples in order to help LT determine if a given sequence of words makes sense or not.

To summarize, this is an opt in feature from LT that makes error checking much better, at the cost of storing those large dataset files.

N grams are sequences of n grammar tokens (not sure about the work) that you find in a given language and the probability to find it. The ngram dataset contains many such examples in order to help LT determine if a given sequence of words makes sense or not.

To summarize, this is an opt in feature from LT that makes error checking much better, at the cost of storing those large dataset files.

Ah ok, thanks for explaining